📦 Manifest – User Manual

✅ 1. Overview

The Manifest Doctype under the VSD Fleet MS module is used to document and manage vehicle trip details and associated cargo. It links a trip to assigned trucks, trailers, drivers, and cargo information, forming the central record for logistical dispatching and tracking.

🛠️ 2. Key Features

Auto-generated Manifest ID using format MNFS-{####}.
Captures transporter type: In House or Sub-Contractor.
Dynamically loads truck, trailer, and driver information based on transporter type.
Links to Trip Route, Trips, and includes Posting Date.
Trailer fields support up to 3 trailers, with conditional visibility based on Has Trailer(s)?.
Captures Manifest Cargo Details via a child table.
Automatically fetches and displays trailer types and truck license plate.
Records total cargo weight (Manifest Total Weight), and supports amendment and tracking.

📝 3. Pre-Requisites

The following master data must be pre-configured:
- Trip Routes
- Trips
- Trucks
- Truck Drivers
- Trailers
User roles with access:
- System Manager
- Any user with “All” role access

🚀 4. Step-by-Step Usage

Step 1: Create a New Manifest

Navigate to: VSD Fleet MS > Manifest > New
Manifest ID auto-generates on save.

Step 2: Select Transporter Type

Choose between In House or Sub-Contractor.

Step 3: Populate Vehicle & Driver Details

For In House:
- Select Truck Number → auto-fetches Truck License Plate, Assigned Driver, Driver Name.
- Check Has Trailer(s)? → enable trailer input fields.
For Sub-Contractor:
- Enter Sub-Contractor Name, Driver Name, Truck Licence Number, and optional trailer info.

Step 4: Assign Trip Route and Date

Select Trip Route (mandatory) → fetches Route Starting Point.
Posting date defaults to today but can be changed.

Step 5: Add Cargo Details

Use the Manifest Cargo Details child table to input cargo information.

Step 6: Submit the Manifest

Once all fields are correctly filled, Save and Submit the document.

🧩 5. Script Customizations

Conditional Fields:
- Visibility and mandatory logic handled using depends_on and mandatory_depends_on.
Fetch Logic:
- fetch_from auto-populates fields like Driver Name, Truck License Plate, and Trailer Type.
Field Filters:
- Logic for trailers and sub-contractor data dynamically adjusts based on transporter_type and has_trailers.

🧯 6. Troubleshooting (Common Errors and Resolutions)

Error/Issue	Cause	Resolution
🚫 Truck is required	Transporter Type is "In House" but truck not selected	Ensure you select a valid truck from the list.
🚫 Driver fields not visible	Transporter Type not set correctly	Verify that "In House" or "Sub-Contractor" is properly selected.
🚫 Trailer fields missing	`Has Trailer(s)?` not checked	Check the `Has Trailer(s)?` box to enable trailer input.
🚫 Field is mandatory	Conditional requirement not met	Ensure required fields (e.g. sub-contractor driver name) are filled when applicable.

👥 7. User Roles and Permissions

Role	Permissions
System Manager	Full access (create, read, write, submit, amend, cancel, delete, share)
All	Same as System Manager (via role-based permission rule)

📌 8. Key Notes

The Doctype uses track_changes for audit and traceability.
Trailer and driver fields dynamically show or hide based on selected Transporter Type.
Up to three trailers can be managed per manifest.
Supports linking and fetching from other Doctypes (Trips, Truck, Trip Routes, Truck Driver, Trailers).

🧠 9. What Business Process Pain Point Does It Help Remove?

The Manifest Doctype centralizes and simplifies trip management by:

Avoiding manual entry duplication for driver, truck, and cargo data.
Enforcing transporter-specific input rules to prevent data entry errors.
Providing a structured and standardized record for each trip and its cargo.
Enhancing operational traceability and regulatory compliance through systematic manifest tracking.

Fleet ms